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(57) Abstract 

The present invention is a method and apparatus for storing static data in a memory. The static data are represented according to a 
resource file structure and included in a source code of an execution code. The source code is compiled to generate a machine code which 
includes the static data and the execution code. The machine code is transferred to the memory. The technique allows access to a data 
held in a data structure embedded in a program code. The data field corresponds to a structure element A pointer to the data field which 
is stored in the data structure is obtained. The data field is retrieved using the pointer. 
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STORAGE OP STATIC DATA FOR 
EFFICIENT ACCESS AND FIELD UPGRADE 

BACKGROUND 

1 . Field of the In vention 

This invention relates to data storage. In 
particular, the invention relates to efficient storage 
of static data. 

2 . Description of Related Art 

Thanks to advances in computer and storage 
technologies, information retrieval programmable devices 
have become popular. Consumers can have portable 
devices to access a large amount of on-board data or 
information downloaded from a communication network. 
Examples of these information retrieval programmable 
devices include Personal Digital Assistant (PDA) and 
electronic book (EB) . 

There are two types of data accessible to a 
programmable device: static data and dynamic data. 
Static data are data that are not modified when the 
device is in use. Examples of static data include 
constants, tables, and fixed image structures. Dynamic 
data are data that are modified dynamically when the 
device is in use. Examples of dynamic data include 
graphic information and computational data structures. 

Static data are usually stored on mass storage 
devices (e.g., disk) as a database system. When the 
programmable device requires the information from the 
database, static data are transferred to on-board random 
access memory (RAM) to allow the processor on the 
programmable device to access directly. 
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The use of a disk subsystem on an information 
retrieval programmable unit presents a number of 
disadvantages. First, a disk subsystem is bulky, 
creating inconvenience to users and difficulty in the 
manufacturing process. Second, a disk subsystem xs 
slow, resulting in long start-up time when the 
programmable unit is powered up and initialized. Third, 
using RAM to store data transferred from a disk 
subsystem is redundant and takes up valuable RAM storage 
space. Fourth, it is inconvenient to upgrade the static 
data in the field or during repair or service. Fifth, 
since a disk subsystem is integrated separately from 
other electronic components on the programmable unit, it 
is uncertain if the static data stored on the disk 
subsystem corresponds to the executable version of the 
on-board program. 

Therefore there is a need in the technology to 
provide a simple and efficient method to store static 
data on an information retrieval device for easy access 
and convenient upgrading. 



HTTMMARY 



The present invention is a method and apparatus for 
storing static data in a memory. The static data are 
represented according to a resource file structure and 
included in a source code of an execution code. The 
source code is compiled to generate a machine code which 
includes the static data and the execution code. The 
machine code is transferred to the memory. The 
technique allows access to a data field in a data 
structure embedded in a program code. The data field 
corresponds to a structure element. A pointer to the 
data field which is stored in the data structure is 
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obtained. The data field is retrieved using the 
pointer . 

BRIEF PFSCRIPTION OF THK DRAWINGS 

The features and advantages of the present 
invention will become apparent from the following 
detailed description of the present invention in which: 

Figure 1 is a diagram illustrating a system in 
which one embodiment of the invention can be practiced. 

Figure 2 is a diagram illustrating an environment 
for storing static data and field update according to 
one embodiment of the invention. 

Figure 3 is a diagram illustrating an resource file 
structure of a resource file representing the static 
data according to one embodiment of the invention. 

Figure 4 is a diagram illustrating a data structure 
of a resource file on a ROM/flash program code according 
to one embodiment of the invention. 

Figure 5 is a flowchart illustrating a process of 
retrieving resource information according to one 
embodiment of the invention. 

Figure 6 is an example of a resource file according 
to one embodiment of the invention. 

Figure 7 is a machine code of the resource file 
shown in Figure 6 according to one embodiment of the 
invention . 

Figure 8A is a source code to store the static data 
for a target processor shown in Figure 7 according to 
one embodiment of the invention. 
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Figure 8B is a source code to store the static data 
for a non-target processor shown in Figure 7 according 
to one embodiment of the invention. 



m?.SPRlPTION 

The present invention is a method and apparatus for 
storing static data on an information retrieval 
programmable device for efficient access and convenient 
field update. The static data are incorporated into the 
program code stored on a programmable or flash memory. 
The static data are organized as a resource file with a 
simple data structure. Upon initialization, the static 
data are accessed efficiently using this simple data 
structure. The static data are also conveniently 
updated remotely or in the field via a communication 
port or by a plug-in replacement of the programmable or 
flash memory. 

In the following description, for purposes of 
explanation, numerous details are set forth in order to 
provide a thorough understanding of the present 
invention. However, it will be apparent to one skilled 
in the art that these specific details are not required 
in order to practice the present invention. In other 
instances, well-known electrical structures and circuits 
are shown in block diagram form in order not to obscure 
the present invention. 

Figure 1 is a diagram illustrating a system in 
which one embodiment of the invention can be practiced. 

Referring to Figure 1, the system 100 comprises: 
(a) at least one portable electronic book 10 operative 
to request a digital content from a catalog of distinct 
digital contents, to receive and .display the requested 
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digital content in readable form; (b) an information 
services system 20 which includes an authentication 
server 32 for authenticating the identity of the 
requesting portable electronic book 10 and a copyright 
protection server 22 for rendering the requested digital 
content sent to the requesting portable electronic book 
10 readable only by the requesting portable electronic 
book 10; (c) at least one primary virtual bookstore 40 
in electrical communication with the information 
services system 20, the primary virtual bookstore being 
a computer-based storefront accessible by the portable 
electronic book and including the catalog of distinct 
digital contents; and (d) a repository 50, in electrical 
communication with the primary virtual bookstore 40, for 
storing the distinct digital contents listed in the 
catalog . 

The system 100 preferably includes more than one 
portable electronic book 10, to be commercially viable. 
This is illustrated in Figure 1 by including the 
portable electronic books 12 and 14. The system also 
preferably includes more than one primary virtual 
bookstore 40, each serving a different set of customers, 
each customer owning a portable electronic book. 

In one embodiment of the invention, the system 100 
further comprises a secondary virtual bookstore 60 in 
electrical communication with the information services 
system 20. In this case, the information services 
system 20 also includes a directory of virtual 
bookstores 26 in order to provide the portable 
electronic book 10 with access to the secondary virtual 
bookstore 60 and its catalog of digital contents. 

The information services system 20 can optionally 
include a notice board server 28 for sending messages 
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from one of the virtual bookstores, primary or 
secondary, to a portable electronic book in the system. 

The information services system 20 also includes a 
registration server 24 for keeping track of the portable 
electronic books that are considered active accounts in 
the system and for ensuring that each portable 
electronic book is associated with a primary virtual 
bookstore in the system. In the case where the optional 
notice board server 28 is included in the information 
services system 20, the registration server 24 also 
allows each portable electronic book user to define 
his/her own notice board and document delivery address. 

The information services system 20 preferably 
comprises a centralized bookshelf 30 associated with 
each portable electronic book 10 in the system. Each 
centralized bookshelf 30 contains all digital contents 
requested and owned by the associated portable 
electronic book 10. Each portable electronic book 10 
user can permanently delete any of the owned digital 
contents from the associated centralized bookshelf 30. 
Since the centralized bookshelf 30 contains all the 
digital contents owned by the associated portable 
electronic book 10, these digital contents may have 
originated from different virtual bookstores. The 
centralized bookshelf 30 is a storage extension for the 
portable electronic book 10. Such storage extension is 
needed since the portable electronic book 10 has limited 
non-volatile memory capacity. 

The user of the portable electronic book 10 can add 
marks, such as bookmarks, inking, highlighting and 
underlining, and annotations on a digital content 
displayed on the screen of the portable electronic book, 
then stores this marked digital content in the non- 
volatile memory of the electronic book 10. The user can 
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also upload this marked digital content to the 
information services system 20 to store it in the 
centralized bookshelf 30 associated with the portable 
electronic book 10, for later retrieval. It is noted 
that there is no need to upload any unmarked digital 
content, since it was already stored in the centralized 
bookshelf 30 at the time it was first requested by the 
portable electronic book 10. 

The information services system 20 further includes 
an Internet Services Provider (ISP) 34 for providing 
Internet network access to each portable electronic book 
in the system. 

Figure 1 further illustrates that the electronic 
books 10, 12, and 14 are used in the field. The 
electronic book 10 may be upgraded via the Internet or 
an upgrade ROM/ flash cartridge 270. 

Figure 2 is a diagram illustrating an environment 
for storing static data and field update according to 
one embodiment of the invention. The environment 200 
includes a development /manufacturing stage 205 and a 
field use stage 206. 

The development /manufacturing stage 205 includes 
the development of prototypes and manufacturing of final 
products. During prototype development or product 
manufacturing, the development /manufacturing stage 205 
stores static data in the information retrieval 
programmable device. The development /manufacturing 
stage 205 includes a resource file structure 210 and a 
read-only memory (ROM) /flash memory 220. The resource 
file structure 210 is a database structure that 
organizes the static data in a predefined format. The 
static data includes data whose values are not changed 
during program execution, or from execution to 
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execution. Examples of the static data include the 
parse tables, images, user interface layout information, 
string constants, etc. Although static data may be 
updated periodically, once they are incorporated into 
the information retrieval programmable device, they are 
not changed during the use of the device. The static 
data can be hard coded into a program's source code. A 
resource file is a database that organizes the static 
data in a structured manner to facilitate information 
access and management. The resource file structure 210 
may include a number of resource files, each 
representing a resource type. The resource file 
structure 210 is incorporated into the ROM/ flash memory 
220. 

The ROM/ flash memory 220 represents a storage 
system in the information retrieval programmable unit. 
The ROM/ flash memory 220 may be implemented by 
semiconductor memories such as programmable read-oniy 
memory (PROM) or flash memory. The ROM/ flash memory 220 
normally stores the program code that is executed by the 
processor in the information retrieval programmable 
unit. Storing the static data in the program code 
instead of a disk system provides a number of 
advantages. First, the ROM/ flash memory 220 is more 
compact, light, reliable, and faster than a disk system. 
Static data can be retrieved quickly, reducing start-up 
time when the unit is initialized at power-up. Second, 
there is no need to use valuable random access memory 
(RAM) storage space to store the static data transferred 
from the disk system. Third, the updating of the static 
data can be conveniently and efficiently performed at 
the field merely by replacing or reprogramming the 
ROM/ flash memory 220. Fourth, the integrity of 
information is maintained by storing static data 
together with program code in the same physical 
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ROM/flash memory. The synchronization of information 
storage is guaranteed when the ROM/ flash memory 220 is 
programmed . 

The program code in the ROM/ flash 220 includes a 
static data structure 222 and an executing code 224. 
The static data structure 222 contains the static data 
transferred or compiled from the resource file structure 
210. The static data structure 222 has a simple data 
structure that allows direct access by the processor. 
The executing code 224 is the code that is executable by 
the processor. The processor can access the static data 
structure 222 by executing the appropriate portion of 
the executing code 224. The executing code 224 also 
contains other functions, routines, subprograms, etc. 
that allows the processor to perform the intended tasks 
of information retrieval in the programmable unit. 

The field use stage 206 is the stage when the unit 
is finalized and is used in the field, either by the 
user or by the field technician. The field use stage 
206 includes the field unit 240. The field unit 240 
represents the final product. The field unit 240 
includes a programmed ROM/ flash memory 250, a processor 
255, and a remote port 260. The programmed ROM/ flash 
memory 250 is the ROM/flash memory 220 that has been 
programmed with the static data in the development/ 
manufacturing stage 205. The processor 255 is any 
processor that can execute the code contained in the 
programmed ROM/ flash memory 250 and access the static 
data structure embedded in the program code. The remote 
port 260 represents a communication port that allows an 
upgrade ROM/flash cartridge 270 to update the programmed 
ROM/ flash memory 250. The upgrade ROM/ flash cartridge 
270 contains the updated program code that replaces the 
program code stored in the programmed ROM/ flash memory 
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250. The replacement of the programmed ROM/ flash memory 
250 can be performed by transferring the contents of the 
upgrade ROM/flash cartridge 270. The transfer can be 
done locally or remotely via a communication network. 
The use of a remote upgrade provides a fast, efficient, 
and convenient upgrading procedure. 

Figure 3 is a diagram illustrating the resource 
file structure 214 of a resource file representing the 
static data according to one embodiment of the 
invention. 

A resource file is a hierarchical organization of 
resource data as static data. The static data may be 
organized as a multi-level data structure. In one 
embodiment, the resource file has two tiered data 
objects, or two levels. The first level is the 
resource type and the second level is the resource 
identification (ID). As illustrated in Figure 3, the 
resource file structure 214 has four fields: a type 
field 310, an ID field 320, a name field 330, and a data 
field 340. 

The type field 310 indicates the resource type. In 
the example shown in Figure 3, the type field 310 has N 
types from TYPE_1 to TYPE_N. In one embodiment, the 
type field is 32-bit or 4-byte long. 'She ID field 320 
indicates the ID code for the corresponding static data. 
In one embodiment, the ID field 320 is 16-bit long. A 
resource type may have a number of different ID's. In 
the example shown in Figure 3, the resource TYPE_1 has 
one ID, ID_1, and the resource TYPE_N has two ID'S, 
ID_N1 and ID_N2 . The name field 330 is optionally 
provided to give the ID a descriptive name. It is 
represented by a string key. In the example shown in 
Figure 3, the ID_1 has a NAME_1, the ID_N1 has a 
NAME_Nl, and the ID_N2 has a NAME_N2 . The data field 
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340 is the value of the corresponding ID. The length 
of the data field depends on the ID of the data, in the 
example shown in Figure 3, the ID_1 has DATA_1, the 
ID_N1 has DATA_Nl, the ID_N2 has DATA_N2. 

The resource file structure 210 is included as part 
of the source code of the program code. During 
development, the source code of the program code is 
compiled and the machine code for the program code is 
produced which include the corresponding static data 
represented as the resource file. The machine code is 
then programmed to the ROM/flash memory for final unit. 
The organization of the static data in the machine code 
has a simple data structure to allow fast access. 

Figure 4 is a diagram illustrating a data structure 
400 of a resource file on a ROM/ flash program code 
according to one embodiment of the invention. 

The data structure 400 of the embedded static data 
as compiled from the source code follows the resource 
file structure 210. However, to facilitate the access 
and management, additional fields are provided. In 
particular, two additional fields are defined: the name 
length field and the data length field. The name length 
field specifies the length of the name. The data length 
field specifies the length of the data field. Using the 
lengths of the name and data fields, it is possible to 
determine the address (or pointer) of any item in the 
resource file. 

The data structure 400 includes a version stamp 
410, type blocks 4201 through 42 ON, and an end of 
resource file indicator 430. 

The version stamp 410 is the version of the 
resource file to provide a track history for the 
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resource file. Tne version stamp 410 provides a means 
for record keeping and for field upgrade. 

The type blocks 4201 to 42 ON are the static data 
organized according to TYPE. Each type block has three 
major parts: a TYPE part, a DESCRIPTOR part, and an 
END_OF_TYPE part. The DESCRIPTOR part contains the 
fields as described in Figure 3 with the addition of two 
fields: the NAME_LENGTH and DATA_LENGTH fields which 
show the length of the name and the data, respectively. 
In the example shown in Figure 4, the type block 4201 
has a part TYPE_1 4301, the DESCRIPTORS part 4401, and 
an END_0F_TYPE_1 part 4601. The DESCRIPTORS part 4401 
includes the following fields: ID_1 4421, name length_l 
4441, NAME_1 446, DATA LENGTH_1 4481, DATA_1 4501, and 
END_OF_TYPE_l 4601. The type block 420N has a TYPE_N 
part 430N, a DESCRIPTOR_Nl part 440N1, a DESCRIPTOR_N2 
part 440N2, and an END_OF_TYPE_N part 460N. The 
DESCRI PTOR_Nl part 440N1 has the following fields: ID_N1 
442N1, NAME__LENGTH_Nl 444N1, NAME_N1 446N1, 
DATA_LENGTH_N1 448N1, and DATA_Nl 450N1. The 
DESCRIPTOR _JJ2 part 440N2 has the following fields: ID_N2 
442N2, NAME_LENGTH_N2 444N2, NAME_N2 446N2, 
DATA_LENGTH_N2 448N2, and DATA_N2 450N2 . 

The end of resource file indicator 430 is a 
delimiter code to indicate the end of the resource file. 

Figure 5 is a flowchart illustrating a process 500 
of retrieving resource information according to one 
embodiment of the invention. 

Upon START, the process 500 obtains the pointer for 
the resource file (Block 510) . The pointer is the 
address offset stored in some fixed location or part of 
the execution code to allow the processor to point to 
the beginning of the data structure. Then the process 
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500 obtains the number of types in the resource file 
(Block 520), and the number of ID'S in each type (Block 
530). Then the process 500 obtains the data lengths of 
the ID'S in each type (Block 540) . 

Using the number of types and the number of ID'S in 
each type, the process 500 determines the pointer for 
the ID k in TYPE j (Block 550) . Then the process 500 
accesses the resource file for the specified type and ID 
using the pointer computed in block 550 (Block 560). 
Then the process 500 is terminated. 

Figure 6 is an example of a resource file according 
to one embodiment of the invention. 

The resource file 600 has a name foo.RES. There 
are two types in the * foo.RES" resource file 600: TYPE 
and TTOO. The TYPE type has two resource ID'S: 1001 and 
1002. The resource ID 1001 has a name *Namel* and a 
data "Datal". The resource ID 1002 has a name *Name2* 
and a data »Data2*. The TTOO type has one resource ID: 
-31782. The resource ID -31782 has an empty name and 
a data *Data3V 

Figure 7 is a binary data 700 of the resource file 
shown in Figure 6 according to one embodiment of the 
invention . 

The binary data 700 represents the static data in 
hexadecimal of the resource file shown in Figure 6. 
The binary data 700 includes an address field 710 and a 
content field 720. The address and content fields are 
in hexadecimal. 

The address field 710 shows the addresses of the 

corresponding static data items. Address location 00 

contains the version number. In this example, the 

version number is 0001. Address location 02 contains 
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the resource type TYPE encoded as u 54 59 50 45". 
Address location 06 contains dummy information reserved 
for future use. Address location OA contains the offset 
for the resource file. This offset is used as a pointer 
to point to the logical beginning of the static data 
structure. The logical beginning of the static data 
structure is at address location 2A. Address location 
0E contains dummy data, reserved for other uses. 

Address location 20 contains the value of *Data2* 
having 5 bytes w 44 61 74 61 32". Address location 25 
contains the value of *Datal* having 5 bytes M4 61 74 
61 31". 

Address location 2A contains the ID number 1002 or 
*03 EA* in hexadecimal. Address location 2C contains 
the size of the data of ID number 1002 which is *Data2*. 
The size of «Data2" is 5, so address location 2C 
contains u 00 00 00 05*. Address location 30 contains 
the offset or pointer to point to ~Data2* . Since 
w Data2* is stored at address location 20, address 
location 30 contains *00 00 00 20". Address location 34 
contains the size of the resource name "Name2*. The 
resource name *Name2* has 5 bytes, so address location 
34 contains *00 05*. Address location 36 contains the 
code for *Name2* which is 5-byte long, ME 51 6D 65 32*. 

Address location 3B contains the ID number 1001 or 
*03 E9* in hexadecimal. Address location 3D contains 
the size of the data of ID number 1001 which is "Datal" . 
The size of "Datal* is 5, so address location 3D 
contains *00 00 00 05*. Address location 41 contains 
the offset or pointer to point to *Datal*. Since 
*Datal* is stored at address location 25, address 
location 41 contains *00 00 00 25*. Address location 45 
contains the size of the resource name *Namel* . The 
resource name "Namel* has 5 bytes, so address location 
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45 contains *00 05". Address location 47 contains the 
code for "Namel" which is 5-byte long, ME 51 6D 65 31". 

Figure 8A is a source code to store the static data 
for a target processor shown in Figure 7 according to 
one embodiment of the invention. 

The first version, compiled under the compiler 
directive #if defined (_MC68K_) is for the target 
programmable device platform. In this example, it is a 
Motorola 68000 family processor. This version is coded 
as a "procedure" having a collection of in-line 
functions. The code is compiled and linked directly 
into a ROM/ flash storable and executable module. 

Figure 8B is a source code to store the static data 
for a non-target processor shown in Figure 7 according 
to one embodiment of the invention. 

The second version, indicated by the compiler 
directive #if not defined OlC68K_) , is built as 
initialized data for use on non-target platforms. 

The present invention provides a simple and 
efficient technique to store static data on an 
information retrieval programmable device. The static 
data are organized as a resource file which is compiled 
together with the program code and stored on a ROM/ 
flash memory. The technique allows fast access and 
convenient field update. 

While this invention has been described with 
reference to illustrative embodiments, this description 
is not intended to be construed in a limiting sense. 
Various modifications of the illustrative embodiments, 
as well as other embodiments of the invention, which are 
apparent to persons skilled in the art to which the 
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invention pertains are deemed to lie within the spirit 
and scope of the invention. 
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CLAIMS 

What is claimed is: 

1. A method for storing static data in a memory, 
the method comprising: 

(a) representing the static data according to a 
resource file structure; 

(b) including the represented static data in a 
source code of an execution code; 

(c) compiling the source code to generate a 
machine code, the machine code including the static data 
and the execution code; and 

<d) transferring the machine code to the memory. 

2. The method of claim 1 wherein the resource 
file structure has a hierarchical organization. 

3. The method of claim 2 wherein the resource 
file structure includes a type field, an ID field, a 
name field, and a data field. 

4. The method of claim 3 wherein resource file 
structure further includes a name length field and a 
data length field. 

5. The method of claim 1 herein compiling 
includes compiling a target version and a non-target 
version. 

6. The method of claim 5 wherein the target 
version corresponds to a target processor platform. 
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7. The method of claim 6 wherein the non- target 
version corresponds to a non- target platform. 

8. A method to access a data field in a data 
structure embedded in a program code, the data field 
corresponding to a structure element, the method 
comprising: 

(a) obtaining a pointer to the data field 
corresponding to the structure element, the pointer 
being stored in the data structure; and 

(b) retrieving the data field using the pointer. 

9. The method of claim 8 wherein the structure 
element has a hierarchical organization. 

10. The method of claim 9 wherein the structure 
element includes a type field and an identification 
field. 

11. The method of claim 10 wherein the structure 
element further includes a name length field and a data 
length field. 

12. The method of claim 9 wherein the structure 
element includes a type field and an identification 
field. 

13. An apparatus comprising: 

a programmed memory that stores a static data 
structure and an execution code, the static data 
structure including a data field, the execution code 
referencing the static data structure; and 

a processor coupled to the memory for executing the 
execution code to obtain a value of the data field. 
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14. The apparatus of claim 13 further comprising: 
an interface port coupled to the processor and the 

memory for interfacing to an upgrade cartridge, the 
upgrade cartridge containing an upgrade memory. 

15. The apparatus of claim 14 wherein the 
processor transfers content of the upgrade memory to the 
programmed memory when the programmed memory needs 
updating. 

16. the apparatus of claim 13 wherein the static 
data structure includes a type field, an ID field, a 
name field, and a data field. 

17. The apparatus of claim 16 wherein the static 
data structure further includes a name length field and 
a data length field. 

18. The apparatus of claim 17 wherein the static 
data structure further includes a data pointer pointing 
to the data field. 

19. The apparatus of claim 18 wherein the 
processor obtains the value of the data field using the 
data pointer. 
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00: 00 01 " Version stamp 

02: 54 59 50 45 - Resource type: TYPE 

06: 00 00 00 00 - Storage bytes "wasted" 

OA: 000000 2A - Resource map offset 

0E: <18 padding bytes > - Padding 

20: 44 61 74 61 32 - Resource data: "Data2 n 

25: 44 61 74 61 31 - Resource data: "Datal" 

2A: 03 EA ~ Resource ID: 1002 

2ci 00 00 00 05 - Data size: 5 

30: 00 00 00 20 - Data offset 

34: 00 05 " Resource name size: 5 

36: 4E 51 6D 65 32 - Resource name: "Name2 p 

3B: 03 E9 - Resource ID: 1001 

3D: 00 00 00 05 - Data size: 5 

41: 00 00 00 25 - Data offset 

45 : 00 05 ~ Resource name size: 5 

47: 4E 61 6D 65 31 - Resource name: "Namel" 



Fig. 7 
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#if defined (_MC68K_) 
extern "C" 

static void Routinel (void) = 
{ 

0x0000, 0x0001, 

// *T\ 'T' , '0', '0' 

0x5454, 0x4F4F, 

0x83DA, 

0x0000, 

// 0x00, 0x00 
0x0000, 

// 0x00, 0x00, 0x00, 0x05 

0x0000, 0x0005, 

// 'D', 'a', 'f , 'a', 

0x4461, 0x7461, 0x3300, 

// 0x80, 0x00 

0x8000, 

II , T ,^ . yi/ .p., 'E 1 

0x5459, 0x5045, 

0x03E9, 

// 0x00, 0x05 
0x0005, 

// *N', 'a', 'm', *e\ 

0x4E61, 0x6D65, 0x3100, 

// 0x00, 0x00, 0x00, 0x05 

0x0000, 0x0005, 

// *D\ 'a', 'f, 'a', 

0x4461, 0x7461, 0x3100, 

// 0x03, OxEA 

0x03EA, 

// 0x00, 0x05 
0x0005, 

// 'N', 'a', 'm', e\ 

0x4E61, 0x6D65, 0x3200, 

// 0x00, 0x00, 0x00, 0x05 

0x0000, 0x0005, 

// *D'. 'a', 't', 'a', 

0x4461, 0x7461, 0x3200, 

// 0x80, 0x00 

0x8000, 

// OxFF, OxFF, OxFF, OxFF 

OxFFFF, OxFFFF, 

0x0000 

}; 

static void Dummy (void) 
{ 

Routinel { ) ,* 

} 

Byte *FooData = (Byte *) Dummy 



#endif 



// Version stamp. 
// Resource type. 

// Resource ID. 

// Resource name length. 

// Data length. 

' 3 ' , 0x00 

// End of resource type. 

// Resource type. 

// Resource ID. 

// Resource name length. 

■ 1 ■ , 0x00 

// Data length. 
•1', 0x00 

// Resource ID. 

// Resource name length. 
'2', 0x00 

// Data length. 
•2', 0x00 

// End of resource type. 

// End of resource file data. 



+ 4; 



Fig. 8a 
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#if not defined ( MC68K_) 

extern "C" 
{ 

static Byte Dummy [] = 



0x00, 


0x00, 


0x00, 


0x01, 


« ip t 




•0' , 


*0', 


0x83, 


OxDA, 






0x00, 


0x00, 






0x00, 


0x00, 






0x00, 


0x00, 


0x00, 


0x05, 




• a ' 


•t\ 


'a' , 


0x80, 


0x00, 






i ip i 


•y , 


'P' , 


■E' 


0x03, 


0xE9, 






0x00, 


0x05, 






'N* , 


• a * 


•m', 


' e ' , 


0x00, 


0x00, 


0x00, 


0x05, 


'D' , 


■a 1 , 


'f. 


'a*, 


0x03, 


OxEA, 






0x00, 


0x05, 






'N' , 


' a' 


'nT, 


* e ' , 


0x00, 


0x00, 


0x00, 


0x05, 


'D' , 


'a', 


■f , 


'a', 


0x80, 


0x00, 






OxFF, 


OxFF, 


OxFF, 


OxFF, 


0x00 









>; 

Byte *FooData = Dummy; 

} 

tendif 



// Version stamp. 

// Resource type. 

// Resource ID. 

// Resource name length. 

// Data length. 
•3', 0x00, 

// End of resource type. 

// Resource type. 

// Resource ID. 

// Resource name length. 
• 1 • , 0x00 , 

// Data length. 

0x00, 

// Resource ID. 

// Resource name length. 
■2 1 , OxDO, 

// Data length. 
•2', 0x00, 

// End of resource type. 

// End of resource file data. 



Fig. 8b 
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